{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "- http://www.gotw.ca/publications/mill18.htm"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This month, I want to present up-to-date answers to two recurring questions about **virtual function**s. These answers then lead directly to four class design guidelines.\n",
    "\n",
    "The questions are old, but people still keep asking them, and some of the answers have changed over time as we've gained experience with modern C++."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# Virtual Question #1: Publicity vs. Privacy?"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "The first of the two classic questions we'll consider is this: \"When should **virtual functions** be `public`, `protected`, or `private`?\" The short answer is: Rarely if ever, sometimes, and by default, respectively - the same answer we've already learned for other kinds of class members.\n",
    "\n",
    "Most of us have learned through bitter experience to make all class members `private` by default unless we really need to expose them. That's just good encapsulation. Certainly we've long ago learned that data members should always be `private` (except only in the case of C-style data structs, which are merely convenient groupings of data and are not intended to encapsulate anything). The same also goes for member functions, and so I propose the following guidelines which could be summarized as a statement about the benefits of privatization."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Guideline #1: Prefer to make interfaces nonvirtual, using Template Method."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Interestingly, the C++ standard library already overwhelmingly follows this guideline. Not counting destructors (which are discussed separately later on under Guideline `#4`), and not double-counting the same virtual function twice when it appears again in a specialization of a class template, here's what the standard library has:\n",
    "\n",
    "- 6 public virtual functions, all of which are `std::exception::what()` and its overrides\n",
    "- 142 nonpublic virtual functions\n",
    "\n",
    "Why is this such a good idea? Let's investigate.\n",
    "\n",
    "Traditionally, many programmers were used to writing base classes using `public virtual function`s to directly and simultaneously specify both the interface and the customizable behavior. For example, we might write:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": 1,
   "metadata": {
    "vscode": {
     "languageId": "cpp"
    }
   },
   "outputs": [],
   "source": [
    "// Example 1: A traditional base class\n",
    "\n",
    "class Widget {\n",
    "   public:\n",
    "    // Each of these functions might optionally be\n",
    "    // pure virtual, and if so might or might not have\n",
    "    // an implementation in Widget; see Item 27 in [1].\n",
    "    //\n",
    "    virtual int Process(Gadget&);\n",
    "    virtual bool IsDone();\n",
    "    // ...\n",
    "};"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "> 1. H. Sutter. More Exceptional C++ (Addison-Wesley, 2002)."
   ]
  }
 ],
 "metadata": {
  "kernelspec": {
   "display_name": "C++17",
   "language": "C++17",
   "name": "xcpp17"
  },
  "language_info": {
   "codemirror_mode": "text/x-c++src",
   "file_extension": ".cpp",
   "mimetype": "text/x-c++src",
   "name": "c++",
   "version": "17"
  }
 },
 "nbformat": 4,
 "nbformat_minor": 2
}
